今天想和大家分享筆者在敏捷框架採用的一點點探索跟思考

框架選擇

敏捷的框架有這麼多種，相信許多人跟我一樣，一開始幾乎無法區分Scrum和Kanban，甚至不知道Lean和XP是什麼。隨著時間的推移，慢慢的原來越熟悉，不僅僅是一開始從網路上查詢到的資訊，而是有更深的親身經歷，進而開始有協助組建團隊，以及更多跟外部社群的交流。

但也慢慢的開始，時常會有人詢問筆者

『我們公司要導入敏捷，你有比較建議用哪一套嗎？我有聽過 Scrum』

或者是

『有建議我們怎麼套用 XXX 嗎』

（此處XXX請自行套用 Scrum、Kanban、Lean、XP等等各種框架）

補充:此系列日誌會以 Scrum為主，筆者過去這接近10年經驗大多都是 Scrum

筆者在回覆這個疑問之前，大多都是先多請詢問的人回想深思這兩個問題
為什麼要導入敏捷?
我們要解決的問題是什麼?

不得不說，有時這讓人陷入了深思，因為它直接觸及我們真正想要解決的核心問題。

那麼，先別管這個問題，在筆者的 Scrum 日常中，我們如何保持角色的清晰和負責呢？讓我們來看看吧

1. What to do

• 產品負責人(Product Owner)
• 產品負責人通常負責定義“要做什麽”，他們會根據業務需求和用戶需求帶進代辦清待(backlog)之中

2. Why to do

• 產品負責人(Product Owner)
• 通常涉及到業務需求和目標，產品負責人需要確保團隊明白每個故事的背後的目的和價值

3. How to do

• 開發團隊 (Development Team)
• 開發團隊會來決定，需要根據“要做什麽”和“為什麽要做”來擬定技術方案與細節

在筆者這近10年的 Scrum之旅中，發現無論是在 Refinement還是 Planning meeting中，更多地探討“為什麼”部分總是有相當的幫助。我們團隊總是喜歡問產品負責人為什麼這樣安排優先度，想知道背後的原因和可能帶來的價值。
甚至還有產品負責人在私下聊天的時候會說，你們團隊真的是很愛問為什麼，他剛加入的時候總是很緊張很有壓力，被問到不知所措，深怕回答得不好，笑著說我們都欺負他。

不只這樣，讓團隊成員提供例子，說明和舉例可以幫助我們更好地理解“要做什麼”。我們嘗試盡可能清晰和具體，以減少資訊傳遞時候的缺失並補充可能遺漏的情況。

而在這一切之中，有一點我學到的是--我們都不是完人。有時候，因為『知識的詛咒』的影響，我們會忘記分享某些重要的信息。但透過開放的溝通和問題討論，我們可以共同努力，一步步向目標前進。

就像開發人員使用小黃鴨除錯法一樣，藉由這樣子簡單的問答，也能夠引出新的想法並補充遺漏的信息，幫助我們共同的去理解產品負責人帶進來的這個任務內容

回到一開始的標題，敏捷框架的選擇真的是你的問題嗎？
希望透過今天的分享，能引起你們的一些思考或找到一些答案！

預告：[Page 2] 迭代的精神

在這些年的 Scrum 經驗之中，有一個影響了筆者很大的點，那就是『迭代』
這兩個字看似簡單，一開始也都會從指南/資料之中查到，但是實際執行的時候呢?
試著回想一下

1. 每個 Sprint是否是逐步的迭代出更完整更好的產品?
2. 每天的工作是否是逐步的迭代出 Sprint goal?
3. 每個小時的工作產出是否都持續迭代出今天預計的要完成的工作內容?
4. 手指敲下的每一個 function 、每一行code、每一個字是否有迭代的精神在裡頭?